Day 2｜為什麼從 Code Review 開始？

18th鐵人賽

nathanfhh

2026-08-10 14:42:10

126 瀏覽

分享至

為何是 Code Review？

在 2024 年當時，我會說：我對於 LLM 這個新技術很有興趣，我也想要應用在我的工作當中。在 2026 年的現在，我會說：還好當年有起這個頭，因為發展到現在之後，由於有 AI 協助，程式寫出來的速度，審查已經跟不上甚至成為了瓶頸。

當時會選用 Code Review 原因很簡單，因為身處醫療環境我們知道這些資料都一定要去識別化、去個資等等的才能送出去。我不想第一次就搞出這樣複雜的架構與流程。因此就把目標轉向程式碼。

程式碼本身就不該有個資、隱私，一些機敏資訊本就該在 GIT 以外的地方進行設定、存取。因此在 GIT 上的程式碼本質的風險就少了許多。

另一個點是過往 Code Review 也是十分費時的流程，我自己審查一份相對中等的大概要 30 分鐘的時間起跳，所以當時就有想過要藉由 AI 的思考能力協助我們進行程式碼審查。

Code Review 手法演化

我的 Code Review 大概歷經幾個變革

第 0 階段：工人智慧

就是人工下去看，我們內部有兩種形式，一個是實體，由異動的同仁講述給審查的同仁聽，即時給出建議與回饋。當然約時間這件事就會讓 Code Review 時間有點推遲。
另一個是我自己在用的線上指派，我自己抽時間看，看完給回饋在內部的 Gitlab 平台上。
我們的基本單位就是 Merge Request。

以上這個背景資訊也影響著後續的發展。

第 0.5 階段：核心流程制定

當時我自己讀了 GitLab API 跟院內平台交互，寫了簡單的 Python Script，並只有在 Terminal 中運作，它會進行以下動作：

讀取我設定在環境變數的 GitLab API Token
取得分派給我的 Merge Request 清單
使用者（我）在 Terminal 中輸入 id 選特定的 MR
Script 再透過 GitLab API 取回該 MR 的 Diff 以及標題、說明送給 LLM （當時也有做出 LLM 選單可以選用不同的語言模型）
LLM 回應的內容（是 Markdown 格式）再藉由 GitLab API 發佈到 MR 的討論串中，交回同仁進行後續檢視與異動

優點很明確，在當時就有感受到極快的審查速度，但是審查品質若用現在的觀點來看肯定不足。

另外最明顯的缺點是當時的 LLM Context Length 有限，所以若異動過多、過大會無法進行審查。

當時跟同仁說這是 Feature 不是 Bug！
有時候在一個 MR 中異動太多確實也是個問題 😂

另外一個是 GitLab API 在單一檔案異動過多時 API 回應會是空白的，這個需要額外留意。

到了第 2、3 階段，讓 AI Agent 可以調用電腦上 git 工具後，這問題就不存在了，它可以自己 clone 並自行取得 diff 內容。

第 1 階段：網頁平台化

0.5 階段的成果主管看到後就鼓勵我想想要怎麼也讓同仁使用？

第一個馬上面臨到的問題就是目前的 OpenAI 金鑰是要提供給 Script 的，若每一個同仁都需要一把，不是不行，而是這會是管理上的災難。當時有想過若要做到那個程度就應該全面導入 LiteLLM。

所以我覺得當下最直觀的做法就是寫成一個網頁服務，同仁提供自己在 GitLab 上的 Token 給這個網頁平台，把 Script 做的事情在網頁上也重現一遍，只是與 LLM 的交互變成由後端統一處理。

對於單一檔案異動過多導致 GitLab API 取不回 Diff 時，我有找到在網頁版中的 Merge Request URL 末端加上 .diff 就會有完整的異動。不過由於不在 API 可自動處理的範圍，所以這個操作就是由網頁代為開啟，請同仁自己複製後貼回來我們網站。

假設 MR 網址是：https://gitlab.{domain}/{group}/ai-code-review/-/merge_requests/1 在後面加上 .diff 變成：https://gitlab.{domain}/{group}/code-review/-/merge_requests/1.diff，這樣就能夠取回所有檔案的異動：

diff --git a/.dockerignore b/.dockerignore
new file mode 100644
index 0000000000000000000000000000000000000000..xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
--- /dev/null
+++ b/.dockerignore
@@ -0,0 +1,5 @@
+lab/
+test/
+tools/
\ No newline at end of file
...

第 2 階段：AI Agent

前一個做法最直觀的問題就是當時 Context 其實蠻少的。

我們只有提供本次 Merge Request 標題、說明，還有程式碼異動的內容給 LLM 進行審查。
因此若本次異動造成原有呼叫行為被異動，原呼叫方可能在運行會報錯，過往就是只能要 LLM 遇到參數、回傳、格式等等有受到異動時要假設原呼叫方的兼容性問題而提出警告，但是只要這次沒有異動到原呼叫方，LLM 就不會看到相關的異動，因此整體的能力是受限的。

AI Agent 出來後，這個問題基本上消失了，我們現在是直接讓 AI Agent 由 MR 異動出發，回頭檢視整個專案，所以它看得夠深也夠廣，整體的能力確實有顯著的提升。

那時候是透過 Claude Code SDK 與電腦上的 Claude Code 進行溝通，但是這樣要有 Claude Code Subscription 的同仁才可以用自己的訂閱來做使用，所以沒有真正的普遍性。